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Actividades del Proceso Eng.2 en ISO 15504/SPICE 


Estandares de Mantenimiento del Software 


ESTANDARES DE MANTENIMIENTO 


Existen numerosos estandares que abordan el problema de la realizacion 
correcta de la fase de mantenimiento del software. Los principales son: 


e Métrica V3[footnote]. Por ser la metodologia de referencia en Espafia. 
METRICA version 3. 2001, Madrid: Ministerio de Administraciones 
Publicas. Secretaria de Estado para la Administracion Publica. Consejo 
Superior de Informatica. 

e ISO/IEC 15504[footnote]. Por ser de los modelos de procesos el de 
caracter mas internacional y, en cierta manera, mas europeo. 

ISO/IEC 15504-1:1998. Information Technology-Software Process 
Assesment, 1998 


Proceso MSI de Métrica Version 3 


Proceso MSI de métrica version 3 


El objetivo de este proceso es la obtencion de una nueva version de un 
sistema de informacion desarrollado con METRICA Version 3[footnote] 6 
Version 2, a partir de las peticiones de mantenimiento que los usuarios 
realizan con motivo de un problema detectado en el sistema, o por la 
necesidad de una mejora del mismo. 

METRICA version 3. 2001, Madrid: Ministerio de Administraciones 
Publicas. Secretaria de Estado para la Administracion Publica. Consejo 
Superior de Informatica. 


En este proceso se realiza el registro de las peticiones de mantenimiento 
recibidas, con el fin de llevar el control de las mismas y de proporcionar, si 
fuera necesario, datos estadisticos de peticiones recibidas o atendidas en un 
determinado periodo, sistemas que se han visto afectados por los cambios, 
en qué medida y el tiempo empleado en la resoluci6n de dichos cambios. Es 
recomendable, por lo tanto, llevar un catalogo de peticiones de 
mantenimiento sobre los sistemas de informacion, en el que se registren una 
serie de datos que nos permitan disponer de la informacion antes 
mencionada. 


En el momento en el que se registra la petici6n, se procede a diagnosticar de 
qué tipo de mantenimiento se trata. Atendiendo a los fines, podemos 
establecer los siguientes tipos de mantenimiento: 


e Correctivo: son aquellos cambios precisos para corregir errores del 
producto software. 

e Evolutivo: son las incorporaciones, modificaciones y eliminaciones 
necesarias en un producto software para cubrir la expansion 0 cambio 
en las necesidades del usuario. 

e Adaptativo: son las modificaciones que afectan a los entornos en los 
que el sistema opera, por ejemplo, cambios de configuracion del 
hardware, software de base, gestores de base de datos, 
comunicaciones, etc. 


e Perfectivo: son las acciones llevadas a cabo para mejorar la calidad 
interna de los sistemas en cualquiera de sus aspectos: reestructuracion 
del codigo, definici6n mas clara del sistema y optimizacion del 
rendimiento y eficiencia. 


Estos dos tltimos tipos quedan fuera del Ambito de METRICA Versi6n 3 ya 
que requieren actividades y perfiles distintos de los del proceso de 
desarrollo. 


Una vez registrada la peticion e identificado el tipo de mantenimiento y su 
origen, se determina de quién es la responsabilidad de atender la peticion. 
En el supuesto de que la peticion sea remitida, se registra en el catalogo de 
peticiones de mantenimiento y continua el proceso. La petici6n puede ser 
denegada. En este caso, se notifica al usuario y acaba el proceso. 


Posteriormente, segun se trate de un mantenimiento correctivo o evolutivo, 
se verifica y reproduce el problema, o se estudia la viabilidad del cambio 
propuesto por el usuario. En ambos casos se estudia el alcance de la 
modificacion. Hay que analizar las alternativas de solucion identificando, 
segun el tipo de mantenimiento de que se trate, cual es la mas adecuada. El 
plazo y urgencia de la solucion a la peticion se establece de acuerdo con el 
estudio anterior. 


La definicion de la solucion incluye el estudio del impacto de la solucién 
propuesta para la peticion en los sistemas de informacion afectados. 
Mediante el analisis de dicho estudio, la persona encargada del Proceso de 
Mantenimiento valora el esfuerzo y coste necesario para la implementacién 
de la modificacion. 


Las tareas de los procesos de desarrollo que va a ser necesario realizar son 
determinadas en funcion de los componentes del sistema actual afectados 
por la modificacion. Estas tareas pertenecen a actividades de los procesos 
Analisis, Diseho, Construccion e Implantacion. 


Por ultimo, y antes de la aceptacion del usuario, es preciso establecer un 
plan de pruebas de regresion que asegure la integridad del sistema de 
informacion afectado. 


La mejor forma de mantener el coste de mantenimiento bajo control es una 
gestion del Proceso de Mantenimiento efectiva y comprometida. Por lo 
tanto, es necesario registrar de forma disciplinada los cambios realizados en 
los sistemas de informacion y en su documentacion. Esto repercutira 
directamente en la mayo r calidad de los sistemas resultantes. 


La estructura propuesta para el Proceso de Mantenimiento de METRICA 
Version 3 comprende las siguientes actividades: 
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Actividad MSI 1: Registro de la peticion 


Actividad MSI1: Registro de la peticion 


El objetivo de esta actividad es establecer un sistema estandarizado de 
registro de informacion para las peticiones de mantenimiento, con el fin de 
controlar y canalizar los cambios propuestos por un usuario o cliente, 
mejorando el flujo de trabajo de la organizaci6n y proporcionando una 
gestion efectiva del mantenimiento. 


Es importante asignar responsabilidades para evitar la realizaci6n de 
cambios que beneficien a un usuario, pero que produzcan un impacto 
negativo sobre otros muchos. Por tanto, es necesario que todas las 
peticiones de mantenimiento sean presentadas de una forma estandarizada, 
que permita su clasificacion y facilite la identificaci6n del tipo de 
mantenimiento requerido. 


Una vez que la peticion ha sido registrada, que ha determinado el tipo de 
mantenimiento y los sistemas de informacion a los que inicialmente puede 
afectar, se comprueba su viabilidad, de acuerdo a las prestaciones de 
mantenimiento establecidas para dichos sistemas de informacion. 
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Tarea MSI 1.1: Registro de la Peticion 


Esta tarea tiene como objetivo registrar las peticiones que los usuarios 
solicitan con motivo de la detecci6n de un problema o por la necesidad de 
una mejora. Se crea un catalogo que constituye un medio para la 
comunicacion entre el usuario o cliente y el responsable de mantenimiento. 


Este catalogo servira de base para abordar, en tareas posteriores, el analisis 
de la peticion, realizar la modificacion solicitada y proporcionar datos 
estadisticos sobre peticiones recibidas o atendidas. 


La informacion que debe incluir dicho registro se determina de acuerdo a 
las normas o estandares existentes en la organizacion para la recepcion de 
peticiones de mantenimiento. En el caso de un error se debe incluir una 
completa descripcion de las circunstancias que llevaron al fallo, adjuntando 
datos de entrada, listados, o cualquier otro material de soporte que se 
considere oportuno. Para peticiones de mejora se debe remitir una 
especificacion de los requisitos a contemplar. 


En cualquier caso, sera imprescindible recoger la identificacion, origen y 
tipo de peticion, asignarle una prioridad inicial e incorporar una 
descripcion, lo mas precisa posible, que facilite su posterior andlisis. 


Productos 

De entrada 

- Peticidn de Mantenimiento (externo) 
De salida 

- Catalogo de Peticiones 

Practicas 

- Catalogaci6n 

Participantes 


- Responsable del Mantenimiento 


Tarea MSI 1.2: Asignacion de la Peticion 


En esta tarea se determina el tipo de mantenimiento requerido por la 
peticion catalogada, teniendo en cuenta toda la informacion que se ha 
registrado en la tarea anterior. Hay que identificar también los sistemas de 
informacion inicialmente afectados por peticion. 


A continuacion, se comprueba que el servicio de mantenimiento, definido 
en el plan de mantenimiento para el sistema de informacion, cubre el tipo 
de mantenimiento que requiere la peticion. Sobre la base de estos criterios, 
se acepta o rechaza la peticion y se notifica a quién corresponda. 


Si la peticion es aceptada, se determina de quién es la responsabilidad de 
atender la solicitud para proceder a su estudio posterior. 


Productos 

De entrada 

- Plan de Mantenimiento (IAS 7.2) 
- Catalogo de Peticiones (MSI 1.1) 
De salida 

- Catalogo de Peticiones: 

o Aceptacion / Rechazo de la Peticion 
o Asignacion de Responsable 
Practicas 

- Catalogacion 

Participantes 


- Responsable del Mantenimiento 


Actividad MSI 2: Analisis de la peticion 


Actividad MSI 2: Analisis de la peticion 


En esta actividad se lleva a cabo el diagnéstico y analisis del cambio para 
dar respuesta a las peticiones de mantenimiento que han sido aceptadas en 
la actividad anterior. 


Se analiza el alcance de la peticion en lo referente a los sistemas de 
informacion afectados, valorando hasta que punto pueden ser modificados 
en funcion del ciclo de vida estimado para los mismos y determinando la 
necesidad de desviar la petici6n hacia el proceso Estudio de Viabilidad del 
Sistema (EVS) o Analisis del Sistema de Informacion (ASI), en funcién del 
impacto sobre los sistemas de informacion afectados. 


El enfoque de este estudio varia segtin el tipo de mantenimiento, teniendo 
en cuenta que en el caso de un mantenimiento correctivo que implique un 
error critico debe abordarse el cambio de forma inmediata sin profundizar 
en el origen del mismo. No obstante, una vez reanudado el servicio, es 
imprescindible analizar el problema y determinar cual es la solucion 
definitiva. 
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Tarea MSI 2.1: Verificacion y Estudio de la Peticion 


Antes de iniciar el estudio de la peticion, se verifica que la informaci6n 
registrada es correcta. 


Para determinar su validez: 


- Si se trata de un mantenimiento correctivo, se debe reproducir el 
problema. 


- En el caso de un mantenimiento evolutivo, hay que comprobar que la 
peticion es razonable o factible. 


Una vez examinada la peticidn comienza su estudio, que sera diferente en 
funcion del tipo de mantenimiento establecido: 


- Si se trata de una peticion de mantenimiento correctivo, y segun el 
acuerdo de nivel de servicio establecido para los sistemas de informacion 
afectados, se evaltia hasta qué punto es critico el problema. Asi es posible 
determinar si la solucion es a corto plazo, es decir, urgente o inmediata, o si 
es a medio 0 a largo plazo: 


- Si el problema es critico, su analisis y soluci6n comienza inmediatamente 
con el fin de reanudar rapidamente el nivel de servicio. Sin embargo, este 
modo de actuacion no elimina la necesidad de una revision posterior del 
problema para valorar los posibles efectos secundarios, establecer una 
solucion definitiva y actualizar todos los productos implicados. 


- Si no es critico, la peticion se clasifica para proceder en la tarea siguiente 
a determinar cual es la soluci6n mas adecuada. 


- En el caso de un mantenimiento evolutivo se delimita su alcance 
determinando si se trata de una modificaci6n a los sistemas de informacion 
inicialmente afectados o de una incorporacion para cubrir nuevas 
funcionalidades no contempladas hasta el momento en dichos sistemas de 
informacion. 


Productos 

De entrada 

- Catalogo de Peticiones (MSI 1.2) 

- Acuerdo de Nivel de Servicio (IAS 8.3) 


De salida 


- Catalogo de Peticiones: 

o Verificacion de la Peticion. 

- Resultado del Estudio de la Peticion 
Practicas 

- Sesiones de trabajo 

- Catalogacion 

Participantes 


- Equipo de Mantenimiento. 


Tarea MSI 2.2: Estudio de la Propuesta de Solucion 


A partir del catalogo de peticiones, y para cada una de ellas, se estima su 
alcance valorando la prioridad inicialmente asignada, de acuerdo a los 
requisitos planteados. A continuacion, se analiza la relacion entre 
peticiones. Se decide cuales pueden abordarse de forma conjunta asignando, 
si procede, una prioridad global a los grupos identificados y determinando 
en qué secuencia deben implementarse los cambios. 


Asimismo, es necesario concretar los requisitos solicitados para cada 
peticion y analizar con mas detalle los sistemas de informacion implicados, 
valorando las caracteristicas de mantenimiento de los mismos y la cantidad 
de cambios sufridos desde su puesta en produccion. 


También se debe comprobar la existencia de otras peticiones en curso que 
afecten a los mismos sistemas de informacion, evaluando la repercusi6n que 
puede tener la realizacion de la peticion de mantenimiento sobre estos 
cambios o desarrollos y analizar su convivencia. Ademas, se analiza el 
impacto que la modificacién puede provocar en el entorno tecnoldgico y en 
los niveles de servicio inicialmente acordados para cada uno de los sistemas 
de informacion, valorando hasta que punto pueden verse comprometidos. 


En el caso de una peticidn de mantenimiento evolutivo, se estudia como 
atenderla teniendo en cuenta la politica de versiones vigente en ese 
momento. Si se trata de una incorporacion o eliminacion, se determina la 
necesidad de llevar a cabo algunas actividades del proceso Analisis del 
Sistema de Informacion de modo previo a la identificacién de los elementos 
afectados. 


Igualmente, se puede tomar la decision de abordar el proceso Estudio de 
Viabilidad del Sistema atendiendo a los requisitos a cubrir, al alcance de la 
modificacion, a las implicaciones en el entorno tecnoldgico, y al ciclo de 
vida estimado para los sistemas de informacion afectados, asi como a la 
existencia de opciones de mercado mas id6éneas. 


En el caso de peticiones de mantenimiento correctivo que hayan precisado 
de una solucion de emergencia, no se daran por cerradas hasta que, o bien 
se compruebe que con dicha solucion el sistema no se ha visto 
comprometido ni tampoco otros sistemas relacionados con él, o bien que 
después de haber aplicado una solucion a corto/medio plazo y realizadas las 
pruebas pertinentes, el sistema conserva su integridad y operatividad. Por 
tanto, una vez que se ha reanudado el servicio, hay que realizar las restantes 
actividades para detectar el origen del problema y asegurar que los cambios 
introducidos no generan otros de mayor envergadura 0 comprometen el 
correcto funcionamiento de otros sistemas de informacion relacionados. 


En cualquiera de las situaciones anteriores, se hace una estimacion 
preliminar del esfuerzo requerido mediante los indicadores establecidos en 
el acuerdo de nivel de servicio para cada sistema de informacion, segun la 
tecnologia aplicada, naturaleza y tamafi del sistema de informacion y los 
tipos de lenguajes utilizados, bases de datos, etc. 


Por ultimo, si se considera necesario, hay que proponer alternativas de 
solucion para dar respuesta de forma satisfactoria a los requisitos 
planteados o problemas detectados, determinando una fecha limite de 
implantacion y un coste aproximado en funcion de la estimacion realizada 
anteriormente. Se elige, junto con el usuario, la soluci6n mas adecuada, y se 
obtiene la aprobacion o rechazo de la peticién. En caso de rechazo, la 
peticion se da por cerrada en el catalogo. 


Productos 

De entrada 

- Plan de Mantenimiento (IAS 7.2) 

- Acuerdo de Nivel de Servicio (IAS 8.3) 
- Catalogo de Peticiones (MSI 2.1) 

- Resultado del Estudio de la Petici6n (MSI 2.1) 
De salida 

- Propuesta de Solucion 

- Catalogo de Peticiones: 

o Estudio del Impacto 

o Aceptacién / Rechazo de la Solucién 
Practicas 

- Sesiones de trabajo 

- Catalogacion 

Participantes 

- Responsable de Mantenimiento 


- Equipo de Mantenimiento 


Actividad MSI 3: Preparacion de la implementacion de la modificacion 


Actividad MSI 3: Preparacion de la implementacion de la 
modificacion 


Una vez finalizado el estudio previo de la peticion y aprobada su 
implementacion, se pasa a identificar de forma detallada cada uno de los 
elementos afectados por el cambio mediante el analisis de impacto. Este 
andlisis tiene como objetivo determinar qué parte del sistema de 
informacion se ve afectada, y en qué medida, dejando claramente definido y 
documentado qué componentes hay que modificar, tanto de software como 
de hardware. 


Con el resultado de este andlisis se dispone de los datos cuantitativos sobre 
los que aplicar los indicadores establecidos. Esto permitira fijar un plan de 
accion, valorando la necesidad de realizar un reajuste de dichos indicadores, 
con el fin de cumplir el plazo maximo de entrega. 


Una vez aceptado el plan de accion, se activan los correspondientes 
procesos de desarrollo para llevar a cabo la implementacion de la solucion. 
Al mismo tiempo, se especifican las pruebas de regresion con el fin de 
evitar el efecto onda en el sistema, una vez realizados los cambios. 
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Tarea MSI 3.1: Identificacion de Elementos Afectados 


Se realiza un analisis detallado del impacto de la petici6n, con el fin de 
conocer el alcance real de la modificacion en funcion del nimero, 
caracteristicas y relaciones existentes entre los elementos afectados. De esta 
manera se puede establecer una secuencia y planificacion correcta del 
desarrollo de los cambios, valorando los recursos necesarios para llevarlo a 
cabo. En el caso de un mantenimiento evolutivo que implique una 
incorporacion o eliminacion, el alcance real de la modificaci6n se determina 
después de realizar el proceso Analisis del Sistema de Informacion, segun 
se indico en la actividad anterior. 


Por tanto, a partir del resultado del estudio obtenido en la actividad anterior, 
se identifica cada sistema de informacion afectado creando argumentos de 
busqueda para determinar qué elementos y en qué medida estan implicados 
en el proceso de cambio. 


En este analisis quedaran reflejados, de la forma que se considere mas 
conveniente, los elementos de la infraestructura tecnolégica (hardware, 
software de base, comunicaciones, etc.) y los elementos asociados a los 
productos software implicados en cada peticién (modelos, pantallas, 
informes, mddulos, programas fuentes, programas objetos, JCL’s, archivos 
de datos, manuales de usuario, manuales de explotacion...), asi como las 
referencias cruzadas. La asociacion de elementos a cada peticion, permitira 
el control de la gesti6n del cambio sobre un mismo elemento. 


Productos 

De entrada 

- Catalogo de Peticiones (MSI 2.2) 
- Propuesta de Solucion (MSI 2.2) 
De salida 

- Catalogo de Peticiones: 


o Elementos Afectados 


- Analisis de Impacto de los Cambios 
Practicas 

- Catalogacion 

- Analisis de Impacto 

Participantes 

- Equipo de Mantenimiento. 


- Jefe de Proyecto 


Tarea MSI 3.2: Establecimiento del Plan de Accion 


Se identifican las actividades y tareas de los procesos de desarrollo Estudio 
de Viabilidad del Sistema, Analisis del Sistema de Informacion, Disenfo del 
Sistema de Informacion, Construccion del Sistema de Informacion e 
Implantaci6n y Aceptacion del Sistema que es preciso realizar, en funcioén 
de las caracteristicas, complejidad y alcance de la peticién estudiada, asi 
como del plan de mantenimiento establecido para los sistemas de 
informacion implicados. 


Una vez delimitado el alcance del plan de accion, se aplican los indicadores 
establecidos para el conjunto de componentes afectados, realizando los 
reajustes que oportunos. Se establece un plan de trabajo en el que se 
determina el coste asociado, los plazos estimados para su implementacién 
con las fechas de comienzo y fin, y la composicion del equipo de trabajo 
inicial necesario, teniendo en cuenta el alcance de la modificacion, el nivel 
de esfuerzo requerido y el plan de trabajo establecido. 


Finalmente, se definen puntos de control que permiten hacer un 
seguimiento del plan de trabajo durante la implementacion de la 
modificacion, determinando con qué frecuencia y en que situaciones se 
llevara a cabo. 


Una vez aprobado el plan de accion y asignados los recursos, se lleva a 
cabo su inicio. 


Productos 

De entrada 

- Plan de Mantenimiento (IAS 7.2) 

- Propuesta de Soluci6n (MSI 2.2) 

- Analisis de Impacto de los Cambios (MSI 3.1) 
- Catalogo de Peticiones (MSI 3.1) 

De salida 

- Catalogo de Peticiones: 

o Actividades y Tareas de los Procesos de Desarrollo a Realizar 
- Plan de Accion para la Modificacion 

Técnicas 

- Planificacion 

Practicas 

- Catalogacion 

Participantes 

- Responsable de Mantenimiento 

- Equipo de Mantenimiento 


- Jefe de Proyecto 


Tarea MSI 3.3: Especificacion del Plan de Pruebas de Regresion 


Las pruebas de regresion tratan de eliminar el llamado efecto onda, es decir, 
que los cambios provocados por una peticion no introduzcan un 
comportamiento no deseado o errores adicionales en otros componentes no 
modificados. Por tanto, es necesario comprobar que los cambios que se 
leven a cabo en los componentes afectados, no produzcan estos efectos 
sobre el mismo u otros componentes. 


Con este objetivo se deben especificar los casos de prueba en funcion de las 
relaciones existentes entre los distintos componentes identificados en la 
tarea Identificaci6n de Elementos Afectados (MSI 3.1). De esta forma, los 
casos de prueba aseguran que la nueva version satisface las necesidades 
planteadas al considerar, a su vez, los sistemas de informacion que no han 
sido modificados pero estan directamente relacionados con ellos y, en 
consecuencia, pueden verse afectados. 


Productos 

De entrada 

- Propuesta de Solucion (MSI 2.2) 

- Analisis de Impacto de los Cambios (MSI 3.1) 
- Catalogo de Peticiones (MSI 3.2) 

De salida 

- Plan de Pruebas de Regresion 

Participantes 

- Equipo de Mantenimiento 


- Jefe de Proyecto 


Actividad MSI 4: Seguimiento y evaluacion de los cambios hasta la 
aceptacion 


Actividad MSI 4: Seguimiento y evaluacion de los cambios 
hasta la aceptacion 


Se realiza el seguimiento de los cambios que se estan llevando a cabo en los 
procesos de desarrollo, de acuerdo a los puntos de control del ciclo de vida 
del cambio establecidos en el plan de accién. Durante este seguimiento, se 
comprueba que solo se han modificado los elementos que se ven afectados 
por el cambio y que se han realizado las pruebas correspondientes, 
especialmente las pruebas de integracion y del sistema. Del resultado 
obtenido se hace una evaluacion del cambio para la posterior aprobacion. 


Una vez finalizado el cambio en desarrollo, se realizan las pruebas de 
regresiOn que especificadas en la actividad anterior, comprobando que 
ningun sistema no modificado, pero con posibilidades de verse afectado, ha 
variado su comportamiento habitual. Se informa si ha habido incidencias 
con el fin de que se resuelvan del modo mas conveniente. Se evaltian las 
pruebas. 


La aprobacion de la peticiOn se realiza al finalizar las pruebas de regresion, 
y después de comprobar que todo lo que ha sido modificado 0 puede verse 
afectado por el cambio, funciona correctamente 


Con el cierre de la petici6n se podran incluir en el catalogo, si se considera 
oportuno, parte de la informacion obtenida durante el proceso de 
mantenimiento que pueda facilitar posteriores analisis. 
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Tarea MSI 4.1: Seguimiento de los Cambios 


Se hace el seguimiento del plan de accion de acuerdo a los puntos de 
control establecidos en la actividad anterior. 


Se realiza el seguimiento de los cambios necesarios en los componentes de 
cada sistema de informacion afectado, asi como en los productos asociados, 
siguiendo las actividades correspondientes a los procesos de Analisis, 
Disefio, Construccion e Implantacién identificadas en la actividad anterior. 


Asimismo, se lleva a cabo el control de la planificacion establecida, que 
abarca los siguientes aspectos: 


- Realizar la traza de los cambios que la peticion ha provocado a lo largo de 
los procesos de desarrollo implicados. 


- Verificar que se han realizado satisfactoriamente las pruebas unitarias, de 
integracion y del sistema que se consideraron necesarias para los 
componentes a modificar. 


- Comprobar que sdlo se ha modificado lo establecido y, en caso contrario, 
justificar el motivo. 


- Asegurar que se han actualizado los productos correspondientes. 


- Llevar el control de los distintos desarrollos existentes en paralelo sobre 
un mismo componente, con el fin de coordinar las modificaciones incluidas 
en cada uno de ellos, y asegurar que en el paso a produccion se implantan 
correctamente. 


Productos 
De entrada 


- Producto Software en Desarrollo (externo, procedente de los procesos de 
desarrollo) 


- Analisis de Impacto de los Cambios (MSI 3.1) (convivencia de distintas 
versiones) 


- Plan de Accion para la Modificaci6n (MSI 3.2) 
De salida 

- Evaluacion del Cambio 

Participantes 

- Equipo de Mantenimiento 

- Responsable de Mantenimiento 


- Jefe de Proyecto 


Tarea MSI 4.2: Realizacion de las Pruebas de Regresion 


Una vez finalizadas las actividades correspondientes al proceso de 
construccion, se realizan las pruebas de regresion definidas en la actividad 
anterior con el objeto de asegurar que ningtin sistema de informacion 
implicado en el cambio ve comprometido su funcionamiento normal. 


En el caso de detectarse problemas, se elabora un informe que recoge las 
incidencias y se remite a quién proceda para que tome las medidas 
correctivas que considere oportunas. 


Finalmente, una vez que el comportamiento es correcto, se documenta el 
resultado global de la evaluacion de las pruebas que incluye la aprobacion 
por parte del responsable de mantenimiento. 


Productos 
De entrada 
- Plan de Pruebas de Regresion (MSI 3.3) 


- Producto Software en Desarrollo (externo) 


De salida 

- Resultado de las Pruebas de Regresion 

- Evaluacion del Resultado de las Pruebas de Regresion 
Practicas 

- Pruebas de Regresion 

Participantes 

- Responsable de Mantenimiento 

- Equipo de Mantenimiento 


- Jefe de Proyecto 


Tarea MSI 4.3: Aprobacion y Cierre de la Peticion 


Se aprueba formalmente la finalizacién de la petici6n de mantenimiento de 
acuerdo a los resultados obtenidos en la tarea anterior. Se actualiza el 
catalogo de peticiones registrando el cierre de la peticion tratada. 


Asimismo, para llevar un control del coste y al mismo tiempo evaluar la 
facilidad de mantenimiento, es conveniente registrar datos cuantitativos 
relativos al tiempo empleado en el analisis de la peticion, en el estudio del 
impacto, resoluci6n del cambio, recursos empleados, etc. 


El registro de este tipo de informacion proporciona una base cuantitativa 
sobre la que tomar decisiones relativas a la eficacia de las técnicas y 
procedimientos de mantenimiento. 


Productos 


De entrada 


- Catalogo de Peticiones (MSI 3.2) 

- Plan de Pruebas de Regresion (MSI 3.3) 
- Evaluacion del Cambio (MSI 4.1) 

- Evaluacion del Resultado de las Pruebas de Regresion (MSI 4.2) 
De salida 

- Catalogo de Peticiones: 

o Nueva version y Aprobacion 

Practicas 

- Catalogacion 

Participantes 

- Directores de los Usuarios 


- Responsable de Mantenimiento 


Participantes en las actividades del proceso Mantenimiento de Sistema de 
Informacion 


Participantes en las actividades del proceso MSI 


MANTENIMIENTO DE ACTIVIDADES 


SISTEMAS DE INFORMACION gi | msi2 | msi3 | Msi4 | 
Directores usuarios | S| S| | 


Equipo de Mantenimiento Pot x |e | x 
Jefe de Proyecto re ee ee 
Responsablede Mantenimiento | x | x | x | x _| 


Actividad 
MSI 1 Registro de la Peticién 

MSI 2 Analisis de la Peticién 

MSI 3 Preparacion de la Implementacion de la Modificacion. 

MSI 4 Seguimiento y Evaluacién de los Cambios hasta la Aceptacién. 


Practicas utilizadas en las actividades del proceso Mantenimiento de 
Sistema de Informacion 


Técnicas/Practicas utilizadas en las actividades del proceso 
MSI 


MANTENIMIENTO DE ACTIVIDADES 


MSI 1 Registro de la Peticion 

MSI2_ Analisis de la Peticion 

MSI3  Preparacion de la Implementacion de la Modificacion 

MS!I4 Seguimiento y Evaluacion de los Cambios hasta la Aceptacion, 


El Proceso Eng.2 en ISO 15504/SPICE 


EL PROCESO ENG.2 EN ISO 15504/SPICE 


El propoésito del Proceso Eng.2[footnote] Mantenimiento de Software y 
sistemas es gestionar las peticiones de modificaciones, migraciones y 
retirada de los componentes de un sistema a peticion de los usuarios. El 
origen de una peticion podria ser descubrir un problema o la necesidad de 
una mejora o adaptacion. El objetivo es modificar y/o retirar un sistema y/o 
un software preservando la integridad de los procesos operativos. Como 
resultado de la implementacion del proceso se obtendra: 

ISO/IEC 15504-1:1998. Information Technology-Software Process 
Assesment, 1998 


e Se desarrollara una estrategia de mantenimiento para gestionar las 
modificaciones, migraciones y cambios de los componentes de 
acuerdo a una estrategia de edicién de versiones. 

e Se actualizaran los documentos de especificaci6n y disefio y los 
sistemas de prueba. 

e Se desarrollaran nuevos componentes modificados del sistema con sus 
pruebas asociadas para demostrar que los requisitos del sistema se 
siguen verificando 

e Las mejoras del sistema y del software se introduciran en el entorno 
productivo del cliente. 


El sistema y el software seran retirados de uso de una manera controlada 
que minimice el impacto sobre la actividad productiva del usuario. 


Actividades del Proceso Eng.2 en ISO 15504/SPICE 


ENG.2.BP1: Determinacion de los requisitos de mantenimiento 


Se determinan los requisitos de mantenimiento del sistema y del software, 
se identifican los elementos del sistema y del software que deben ser 
mantenidos y las mejoras requeridas. 


ENG.2.BP2: Desarrollo de la estrategia de mantenimiento 


Se desarrolla una estrategia para gestionar las modificaciones, las 
migraciones y la retirada de los componentes del software o del sistema. 


ENG.2.BP3: Analizamos los problemas de usuario y las 
mejoras 


Se analizan los problemas de usuario y las peticiones de las mejoras 
requeridas, se evalua el posible impacto de cada una de las posibles 
soluciones debido a las modificaciones que introducirian en sistema, en las 
interfaces de usuario o en los requisitos 


ENG.2.BP4: Determinar las modificaciones para la nueva 
version 


Basandose en el analisis anterior se determinan que modificaciones deben 
ser aplicadas en el pr6ximo sistema o actualizacion del software, 
documentando que aspectos del software, unidades u otros elementos del 
sistema seran cambiados y que pruebas se necesitan para garantizar el 
correcto funcionamiento de dicho cambios. 


ENG.2.BP5: Implementacion y pruebas de las modificaciones 


Se utilizan otros procesos del software como el de implementaci6on y 
pruebas para demostrar que el funcionamiento y la operatividad del sistema 


o el software actuales no se van a ver comprometidos por los cambios o 
mejoras previstas en el proyecto de mantenimiento. 


ENG.2.BP6: Puesta en produccion de la nueva version del 
sistema 


Se realiza la migraciOn del sistema y el software con las modificaciones o 
mejoras introducidas en el entorno de trabajo del usuario, proporcionando: 


e Operatividad en paralelo entre el sistema antiguo y el Nuevo 
e Formacion adicional para los usuarios, siempre que se necesite 


e Operaciones de soporte 
e Retirada del sistema antiguo 


ENG.2.BP7: Retirada del sistema antiguo 


Siguiendo la aprobacion se retira el sistema antiguo del entorno productivo 
del usuario, proporcionado, siempre que sea necesario: 


Operatividad en paralelo 

Conversion de los datos para su utilizacion en el nuevo sistema 
e Actualizacion de los archivos 

e Formacion de los usuarios para el programa de conversion. 


